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improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
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Abstract 


This document defines a mechanism for the backhauling of V5.2 
messages over IP using the Stream Control Transmission Protocol 
(SCTP). This protocol may be used between a Signaling Gateway (SG) 
and a Media Gateway controller (MGC). It is assumed that the SG 
receives V5.2 signaling over a standard V5.2 interface. 


This document builds on the ISDN User Adaptation Layer Protocol (RFC 


3057). It defines all necessary extensions to the IUA Protocol 
needed for the V5UA protocol implementation. 
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1. Introduction 


This document describes a method of implementing V5.2 backhaul 
messaging over IP using a modified version of the ISDN User 
Adaptation Layer Protocol (IUAP) [1]. V5UA builds on top of IUA, 
defining the necessary extensions to IUA for a V5.2 implementation. 


Since V5UA is meant to be an extension to IUAP, everything defined in 
[1] is also valid for V5UA unless otherwise specified in this 
document. 
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This document does not describe the V5 standard itself. The V5 


protocol is defined by ETSI standards [2,3]. Any description of the 
V5 protocol in this document is meant to make the text easier to 
understand. 


1.1. Scope 
There is a need for Switched Circuit Network (SCN) signaling protocol 
delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway 
Controller (MGC), analogous to the implementation of the ISDN Q.921 
User Adaptation Layer (IUA) as described in [1]. 


This document supports analog telephone access, ISDN basic rate 
access and ISDN Primary rate access over a V5.2 interface. 


Since the V5.2 Layer 2, and especially Layer 3, differs from the 
Q.921 [4] and Q.931 Adaptation layer, the IUA standard must be 
extended to fulfil the needs for supporting V5.2. 
1.2. Terminology 
Bearer Channel Connection (BCC) protocol - A protocol which allows 
the Local Exchange (LE) to instruct the Access Network (AN) to 
allocate bearer channels, either singularly or in multiples, on 


demand. 


Communication channel (C-channel) - A 64 kbit/s time slot on a V5.2 
interface provisioned to carry communication paths. 


Communication path (C-path) - Any one of the following information 
types: 


- The layer 2 data link carrying the Control protocol 

- The layer 2 data link carrying the Link Control protocol 

- The layer 2 data link carrying the PSTN signaling 

- Each of the layer 2 data links carrying the protection protocol 
- The layer 2 data link carrying the BCC protocol 

- All the ISDN Ds-type data from one or more user ports 

- All the ISDN p-type data from one or more user ports 


- All the ISDN t-type data from one or more user ports 
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Note: This definition includes the possibility that there may be 
more than one C-path of the same information type, each allocated 
to a different logical C-channel. 


Envelope Function Address (EFA) - 13 bit number, ranging from 0 to 
8191 (decimal). An EFA uniquely identifies one of the five V5.2 
protocols, or an ISDN agent attached to an AN. The following list 
contains the possible values for the EFA: 


Definition Value 
ISDN_PROTOCOL 0-0 = BLK 
PSTN_PROTOCOL 8176 
CONTROL_PROTOCOL 8177 
BCC_PROTOCOL 8178 
PROT_PROTOCOL 8179 
LINK_CONTROL_PROTOCOL 8180 
RESERVED 8181 - 8191 
Layer 1 Functional State Machine (L1 FSM) - Functional State Machine 


in V5 System Management that tracks and controls the states of the 
physical El links on the interface. 


Logical Communication channel (Logical C-channel) - A group of one or 
more C-paths, all of different types, but excluding the C-path for 
the protection protocol. 


Multi-link - A collection of more than one 2048 kbit/s link which 
together make up a V5.2 interface. 


Multi-Slot - A group of more than one 64kbit/s channels providing 
8Khz and time slot sequence integrity, generally used together 
within an ISDN Primary Rate Access (ISDN-PRA) user port, in order 
to supply a higher bit-rate service. 


Physical Communication Channel (Physical C-channel) - A 64kbit/s time 
slot on a V5.2 interface which has been assigned for carrying 
logical C-channels. A physical C-channel may not be used for 
carrying bearer channels. 


Primary Link - A 2048 kbit/s (El) link in a multi-link V5.2 interface 
whose physical C-channel in time slot 16 carries a C-path for the 
protection protocol and, on V5.2 initialization, also the C-path 
for the control protocol, link control protocol, and the BCC 
protocol. Other C-paths may also be carried in the time slot 16. 
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Secondary Link - A 2048 kbit/s (El) link in a multi-link V5.2 
interface whose time slot 16 carries a C-path for the protection 
protocol, and, on V5.2 initialization, acts as the standby C- 
channel for the control protocol, link control protocol, and BCC 
protocol and any other C-paths initially carried in time slot 16 
of the primary link. 


v5 Link - A 2048 kbits/s El (PCM30) link used on a V5 interface. A 
V5 interface may use up to 16 V5 links. 


1.3. V5.2 Overview 
v5.2 is an industry standard ETSI interface (reference ETS 300 347-1 


[3]) defined between a Local Exchange (LE) and an Access Network (AN) 
providing access to the following types: 


- Analog telephone access 
- ISDN Basic rate access 
- ISDN Primary Rate access 


- Other analog or digital accesses for semi-permanent connections 
without associated outband signaling information 


The original V5 specification (V5.1 [2]) uses 2048 kbps links ina 
non-concentrating fashion. In contrast, V5.2 may use up to 16 such 
interface links and supports concentration. 


The LE and AN are connected with up to 16 El (PCM30) links. Channels 
16, 15 and 31 on any El link can be reserved for data communication 
between LE and AN. The channels reserved for data are called 
"Communication Channels" or "C-channels." 


The C-channels are the physical media that exchange data between the 
V5.2 protocol peer entities, as well as transfer the ISDN BRI 
D-channel messages between the terminals and the LE. A logical 
communication path between two peer entities for one protocol is 
called a "C-path". 
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The signaling information in V5.2 are defined as: 


- Analog signals are carried by means of the V5 PSTN protocol 
(L3) 


- ISDN/analog ports are controlled by the V5 Control protocol 
(L3) 


- ISDN protocol messages are mapped to LAPD frames, which are 
carried by means of LAPV5-EF sublayer (L2) 


- V5 protocol messages are mapped to LAPV5-DL frames, which are 
carried by means of LAPV5-EF sublayer (L2) 


In order to support more traffic and dynamic allocation of bearer 
channels, the V5.2 protocol has several additions: 


- A bearer channel connection protocol establishes and 
disestablishes bearer connections on demand, as determined by 
the signaling information, under the control of the Local 
Exchange. 


- A link control protocol is defined for multi-link management to 
control link identification, link blocking and link failure 
conditions. 


- A protection protocol, operating on two separate V5 data links 
is defined to manage the protection switching of communication 
channels in case of link failures. 


The following protocols are defined for the various protocol layers: 


Layer 2: 
- LAPV5-EF 
- LAPV5-DL 


Layer 3: 
- V5-Link Control 
— V5-BCC 
— V5-PSTN 
- V5-Control 
- V5-Protection 
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1.4. Distribution of responsibilities between MGC and SG 


In the V5UA backhaul architecture, the V5 protocol entities SHALL be 
distributed over SG and MGC as shown below. 


MGC SG 
4+------------ + 4+------- 4+------- + 
| Lnk Cntrl | | | | 
+------------ + 
| Cntrl | | | | 
+------------ + V5UA | | | v5 +------ + 
| BCC | <-------- > | LAPV5 | LAPV5 | <----> | AN 
Ho + | -DL | -EF | +------ + 
| PSTN | | | | 
acacia ea SiGe + | | | 
| Protection | | | | 
+------------ + +------- +------- + 


V5 System Management SHALL be located on the MGC. The V5 Ll 
Functional State Machine (FSM) SHALL be located on the SG. 


Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the 
MGC. 


1.5. Client/Server Model 


The Client/Server Model for V5UA shall follow the model as defined 
for IUAP. 


The SCTP [6] (and UDP/TCP) registered User Port Number Assignment for 
V5UA is 5675. 


1.6. Addition to boundary primitives 
1.6.1. V5 specific boundary primitives 


Extending IUAP to V5UA to support V5.2 backhaul requires the 
introduction of new boundary primitives for the Q0.921/0.931 boundary, 
in accordance with the definitions in the V5 standards. 


V5UA reuses some IUA primitives from the Q0.921/0.931 boundary: the 
DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA 
primitive is used for the transportation of both V5 Layer 3 messages 
and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only 
used for V5 ISDN messages and is used and defined as described for 
IUAP. 
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In the V5 standards, V5 system management is responsible for 
establishing and releasing data links. Therefore, for V5UA the DL- 
Establish and DL-Release primitives defined in IUAP are replaced by 
new primitives between system management and the data link layer in 
accordance with the definitions in [2]: 


MDL-ESTABLISH 


The MDL-Establish primitives are used to request, indicate and 
confirm the outcome of the procedures for establishing multiple frame 
operation. 


MDL-RELEASE 


The MDL-Release primitive is used to indicate the outcome of the 
procedures for terminating multiple frame operation. 


In contrast to ISDN, the V5 standards demand that V5.2 system 
management interacts directly with V5.2 layer 1. Since V5.2 Layer 1 
(including the L1 FSM) and parts of V5 system management are 
physically separated in a V5 backhaul scenario, V5UA must support 
some services for the communication between these two entities. 
Specifically, these services include an indication of the status of a 
specific link, and messages to support the link identification 
procedure defined by the V5 standards. 


The new primitive are defined as shown below: 
MPH-LINK STATUS START REPORTING 


The MPH-LINK STATUS START REPORTING primitive is used by V5 system 
management to request that a link be brought into service for use in 
a V5 interface. On reception of this message, the L1 FSM on the SG 
SHALL start reporting the status of the V5 link to the MGC. This 
primitive is used similarly to the MPH-proceed primitive defined by 
v5.2, but it has a more extended meaning than MPH-proceed. 


MPH-LINK STATUS STOP REPORTING 


The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system 
management to request that a link be taken out of service on a V5 
interface. On reception of this message, L1 FSM on the SG SHALL stop 
reporting the status of the V5 link to the GWC. This primitive is 
used similarly to the MPH-stop primitive defined by V5.2, but it has 
a more extended meaning than MPH-stop. 
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MPH-LINK STATUS INDICATION 


The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the 
Signaling Gateway to report the status (operational/non-operational) 
of a V5 link to V5 system management. This primitive is equivalent 
to the MPH-AI and MPH-DI primitives in V5.2. 


MPH-SA-BIT SET 


The MPH-SA-BIT SET primitive is used by system management to request 
that the L1 FSM in the SG sets or resets the value of a specified Sa 
bit on the requested link. The SG uses it to report the successful 
setting or resetting of this bit back to system management. For V5, 
this message is used for the V5 specific Link Identification 
procedure to set/reset the value of the Sa7 bit, or to confirm the 
successful setting of the Sa bit. The MPH-SA BIT SET REQUEST is 
equivalent to the MPH-ID and MPH-NOR primitives in V5.2. 


MPH-SA-BIT STATUS 


The MPH-SA-BIT STATUS primitives are used by system management in the 
MGC to request that the L1 FSM in the SG reports the status of a 
specified Sa bit on the requested link. The SG uses it to report 
(indicate) the status of this bit back to system management. For V5, 


Weilandt, 


these messages are used for the V5 
procedure to request or report the 
equivalent to the MPH-IDR, MPH-IDI 


Due to the separation of V5 System 
the V5UA backhaul architecture, it 
conditions of the SG's V5 stack to 
purpose, 


MDL-ERROR INDICATION 


The MDL-ERROR INDICATION primitive 
condition to V5 System Management. 
primitive is 'Overload', 
C-channel on the SG. 
standards. 


Conventions 


The keywords MUST, MUST NOT, 
SHOULD NOT, 
they appear in this document, 
Bag 


et al. Standards 


REQUIRED, 
RECOMMENDED, NOT RECOMMENDED, MAY, 
are to be interpreted as described in 


specific Link identification 
status of the Sa7 bit. This is 
or MPH-Elg primitives in V5.2. 


Management and V5 Layerl/Layer2 in 
may be necessary to report error 
V5 System Management. For this 


a new primitive is defined: 


is used to indicate an error 
The only valid reason for this 


indicating an overload condition of the 
This reason is not defined in the V5/Q.921 


SHALL, SHALL NOT, SHOULD, 


and OPTIONAL, when 
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A single SCTP stream SHOULD be used for grouping all of the following 


protocols together: 
specific C-channel. 


Protection protocol on a specific C-channel. 
be used for all ISDN user ports on a specific C-channel. 


BCC, Link Control, 


Control and PSTN protocol on a 


A separate SCTP stream SHOULD be used for the 


One SCTP stream SHOULD 
One single 


stream SHOULD NOT be used to carry data of more than one C-channel. 


In addition, 
(link related) 


4. Proposed V5.2 Backhaul Architecture 


KKKKKK 
Se * SG Ko a 
KKKKKK 
(NIF) 
4+---------- + 
| | V5UA| 

+=---+ 
| LAPV5 | SCTP | 
| +----+ 
| | IP + 
4+----- 4+----+ 


one separate SCTP stream SHOULD be used for all MPH 
messages. 


Figure 1: V5.2 Backhaul Architecture 


AN - Access Network 

NIF - Nodal Interworking Function 

SCTP - Stream Control Transmission Protocol 
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4.1. V5UA Message Header 


The original IUA message header must be modified for V5UA. The 
original header for the integer formatted Interface Identifier is 
shown below: 


1 2 3 
1.2234 :9:06-,7:8:90. 11.2 3:4.5.6 718 9.0.1 :2.3.4 06:71 8-90 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tag (0x1) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Interface Identifier (integer) 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tag (0x5) | Length=8 | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
DCT | Spare | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


A a ti 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 


Figure 2: Original IUA Message Header 


V5UA extends the IUA Message Header by including the Envelope 
Function Address (EFA) in the Spare field. The V5UA format for the 
integer formatted Interface Identifier is shown below: 


1 2 3 
I 23 AO (6? OL AS Aa o 1 8 0d 23 0 6T g9 OLL 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tag (0x1) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Interface Identifier (integer) 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tag (0x81) | Length=8 | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
DLCI | EFA | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


A OS 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 


Figure 3: V5UA Message Header (Integer-based Interface identifier) 


Weilandt, et al. Standards Track [Page 11] 


RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004 


The EFA is defined by the V5 standard. It identifies a C-path, which 
is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA 
uniquely identifies one of the five V5.2 protocols, or an ISDN agent 
attached to an AN. The following list contains the possible values 
for the EFA as defined by V5: 


Definition Value 
ISDN_PROTOCOL 0 - 8175 
PSTN_PROTOCOL 8176 
CONTROL_PROTOCOL 8177 
BCC_PROTOCOL 8178 
PROT_PROTOCOL 8179 
LINK_CONTROL_PROTOCOL 8180 
RESERVED 8181 - 8191 


For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA 
SHALL be set to ZERO and SHALL be ignored by the receiver. For all 
other messages, the DLCI SHALL be set as defined in the V5.2 standard 
[2]. 


The Interface Identifier SHALL follow the naming conventions for the 
Interface Identifier as defined below. 


4.2. V5 Naming Conventions for Interface Identifier 


The V5 standard demands that V5 System Management keep track of the 
states of all links on a V5 interface. To perform tasks like 
protection switching and bearer channel allocation on the V5 links, 
it is necessary that system management has the full picture of the 
signaling and bearer channels located on each link. 


The IUA protocol identifies C-channels by endpoints without a defined 
association with a specific link. Since no naming convention exists, 
there is no guarantee that a C-channel is actually located at the 
link it claims to be. Furthermore the V5 standard requires that the 
MGC receives reports of the status of all links, and it defines a 
link identification procedure to ensure that AN and LE are 
referencing the same link when they address a link with a Link 
Control Protocol message. 


It would clearly be against the concept of V5.2 if there was no clear 


association between El links and channels. To solve this problem, a 
naming convention MUST be used for V5UA. 
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The format of the integer formatted Interface Identifier is shown 
below: 


0 1 2 3 
01234567890123456789012345678090 I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Link Identifier | Chnl ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Link Identifier - Identifier for an El link on the SG (27 bits). 
MUST be unique on the SG. This Link Identifier MUST match the 
Link Identifier used in the Link Management Messages defined later 
in this document. 


Chnl ID - Channel Identifier (5 bits). This is equal to the time- 
slot number of the addressed time slot. Possible values are 15, 
16 and 31 representing the possible time slots for C-channels on a 
v5 interface. For Link Management Messages, the Chnl ID MUST be 
set to 0. All other values are reserved for future use. 


If used, the text formatted interface identifier SHALL be coded as 
the hex representation of the integer formatted interface identifier, 
written as a variable length string. 


4.3. V5 Additions to IUA Boundary Primitives 


Some primitives for the V5 interface boundaries are similar to the 
0.921/0.931 boundary primitive messages defined in IUA, but they need 
to be handled in a different way. Therefore it is neccessary to 
distinguish between these two message types by means of the Message 
Class parameter. 


For all V5 interface boundary primitives, a new Message Class is 
introduced: 


14 V5 Boundary Primitives Transport 
Messages (V5PTM) 


Other valid message classes for V5UA, which are also used by IUA, 


are: 
0 Management (MGMT) Message 
3 ASP State Maintenance (ASPSM) Messages 
4 ASP Traffic Maintenance (ASPTM) Messages 


Weilandt, et al. Standards Track [Page 13] 


RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004 


0.921/0.931 boundary primitive messages reused by V5.2 as V5PTM 
messages are: 


1 Data Request Message (MGC -> SG) 
2 Data Indication Message (SG -> er 
3 Unit Data Request Message (MGC -> SG) 
4 Unit Data Indication Message (SG -> Hse) 
5 Establish Request (MGC -> SG) 
6 Establish Confirm (SG -> to 
7 Establish Indication (SG -> zara 
8 Release Request ae -> SG) 
9 Release Confirm (S See, 
10 Release Indication (S > MGC) 


All these messages are defined similarly to the QPTM messages. 
In addition, new boundary primitive messages are defined: 


11 Link Status Start Reporting (MGC -> SG) 
12 Link Status Stop Reporting (MGC -> SG) 
13 Link Status Indication (SG -> MGC) 
14 Sa-Bit Set Request (MGC -> SG) 
1:5 Sa-Bit Set Confirm (SG -> MGC) 
16 Sa-Bit Status Request (MGC -> SG) 
17 Sa-Bit Status Indication (SG -> MGC) 
18 Error Indication (SG -> MGC) 


4.4. Link Status Messages (Start Reporting, Stop Reporting, Indication) 


The Link Status Messages are used between V5 System Management on the 
MGC and the L1 FSM on the SG to track the status of a particular El 
link. This is required whether or not the El link carries 
C-channels. 


All Link Status Messages contain the V5UA Message Header. The Link 
Identifier portion of the Interface Identifier identifies the 
physical link on the SG addressed by the message. For all link 
status messages, the Chnl ID SHALL be set to ’0’ and SHALL be ignored 
by the receiver. 


The integer value used for the Link Identifier is of local 
Significance only, and is coordinated between the SG and MGC. It 
MUST be unique for every V5 link on the SG. 


As defined by the V5 standards, V5 System Management must know the 
status of the links on all active V5 interfaces. The Link Status 
Start Reporting Message is used by V5 System Management on the MGC to 
request that the L1 FSM on the SG starts reporting the status of a 
particular link. 
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v5 system management SHALL send this Message on interface activation 
for all links on the interface. The SG SHALL respond immediately to 
this request with a Link Status Indication message, and it SHALL then 
send a Link Status Indication message on all subsequent changes of 
the link status. Since the SG has no other way to determine whether 
a link is on an active interface or not, this message SHALL always be 
sent on interface startup. 


If the L1 FSM in the SG receives a Link Status Start Reporting 
Message for a link that is already active (the link status is 
reported to System Management), the SG SHALL immediately report the 
actual status of this link by sending a Link Status Indication 
Message. The SG SHALL then proceed with the automatic link status 
reporting as described above. 


To stop this reporting of the status of a link, e.g., at interface 
deactivation, System Management sends a Link Status Stop Reporting 
Message to the L1 FSM. The SG will then immediately stop reporting 
the status of the particular link and will assume the link to be out 
of service. It MUST NOT respond in any way to this message. 


Since there is no other way for the SG to know that an interface has 
been deactivated, this message SHALL be sent on interface 
deactivation for all links on the interface. On reception of this 
message, the SG SHALL take L2 down on this link. 


If the L1 FSM in the SG receives a Link Status Stop Reporting Message 
for a link that is not active (the link status is not reported to 
System Management), the SG SHALL ignore the message. 


The Link Status Start/Stop Reporting Messages contain the common 
message header followed by the V5UA message header. They do not 
contain any additional parameters. 


The Link Status Indication Message is used by L1 FSM in the SG in 
response to a Link Status Start Reporting Message to indicate the 
status of the particular link. After a Link Status Start Reporting 
Message has been received by the L1 FSM, it SHALL automatically send 
a Link Status Indication Message every time the status of the 
particular link changes. It SHALL not stop this reporting until it 
receives a Link Status Stop Report Message from System Management. 


The Link Status Indication Message contains the common message header 


followed by the V5UA message header. In addition, it contains the 
following link status parameter: 
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The valid values for Link Status are shown in the following table: 


Define Value Description 
OPERATIONAL 0x0 Link operational 
NON-OPERATIONAL 0x1 Link not operational 


4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request, 
Status Indication) 


The Sa-Bit Messages are used between V5 System Management in the MGC 
and the L1 FSM in the SG to set and read the status of Sa bits on the 
El links. For V5, it is only required to set and read the status of 
the Sa7 bit that is used for the Link Identification procedure as 
described by the V5 standards [3]. 


All Sa-Bit Messages SHALL contain the V5UA message header. The Link 
Identifier portion of the Interface Identifier identifies the 
physical link on the SG addressed by the message. For all link 
status messages, the Chnl ID SHALL be set to ’0’ and SHALL be ignored 
by the receiver. 


The Link Identifier MUST be the same as used in the Interface 
Identifier to identify on which link a C-channel is located. 


The Sa-Bit Set Request message is used to set the value of the 
specified Sa-Bit on the defined link. The value of the Sa7 bit in 
normal operation is ONE. For the Link Identification procedure, it 
is set to ZERO. 


The Sa-Bit Set Request message for the Sa7 bit with Bit Value ZERO 
corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set 
Request message for the Sa7 bit with Bit Value ONE corresponds to the 
V5 defined primitive MPH-NOR. 


The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set 
Confirm message when the setting of the bit is complete. This 
message does not correspond to a V5 defined primitive. 
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The Sa-Bit Status Request message is used by system management to 
request the status of the specified Sa-Bit on the defined link from 
L1 FSM. The Sa-Bit Status Request message for the Sa7 bit 
corresponds to the V5 defined primitive MPH-IDR. 


L1 FSM answers the Sa-Bit Status request message by a Sa-Bit Status 
Indication message in which the current setting of the bit will be 
reported. The Sa-Bit Status Indication message for the Sa7 bit with 
Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The 
Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE 
corresponds to the V5 defined primitive MPH-Elg. 


All Sa-Bit Messages contain the following additional parameter: 
0 1 2 3 


OE 2:34:29) 00101 899, 300142: 35428 6 8, 90 OL 2 3-4-00.06*1 78: 9, “Oral 
dd AO A A O O O O AO A O O O O A O O O A O O O A O O A o O Ho + 


| Tag (0x83) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| BIT ID | Bit Value | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The valid values for Bit Value are shown in the following table: 


Define Value Description 
ZERO 0x0 Bit value ZERO 
ONE 0x1 Bit value ONE 


The valid value for BIT ID is shown in the following table: 
Define Value Description 
Sa7 0x7 Addresses the Sa7 bit 


There are no other valid values for V5UA. All other values are 
reserved for future use. 


For the Sa-Bit Status Request and Set Confirm messages, the BIT Value 
SHALL be set to '0” by the sender and SHALL be ignored by the 
receiver. 

4.6. Error Indication Message 
The Error Indication Message is used between the V5 stack on the SG 


and the V5 System Management in the MGC to indicate an error 
condition at the SG. 
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The only valid reason for the Error Indication Message is Overload. 


The SG SHOULD issue such an Error Indication with reason Overload for 
a C-channel if it is not able to process all Layer 3 messages on this 


C-channel in a timely manner (overload condition of the C-channel). 


The Error Indication message SHALL contain the V5UA message header. 


The Interface Identifier indicates the affected C-channel. SAPI, TEI 


and EFA SHALL be set to ’0’ and SHALL be ignored by the receiver. 


The Error Indication message contains the following additional 
parameter: 


0 1 2 3 
0123456789012345678901234567800m1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Tag (0x84) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Error Reason | 
doo o o o o o o o o o o o o o o o o o o o o o o o o o o o o o + 


The valid values for Error Reason are shown in the following table: 
Define Value Description 
OVERLOAD 0x1 C-channel is in overload state 


There are no other valid values for V5UA. All other values are 
reserved for future use. 


Procedures 
V5 Layer 1 failure 


The normal way to handle a V5 Layer 1 failure is described in the V5 
standards[2,3] as follows: 


- The L1 FSM detects the V5 Layer 1 failure. It reports this to 
V5 System management by sending a MPH-DI primitive for the 
affected link. 


- V5 System management notifies V5 Layer 2 of the V5 Layer 1 
outage by sending a MPH-Layer_1 Failure Ind primitive. 


Since V5 Layerl/2 and V5 System Management are no longer co-located 
in the backhaul architecture, it does not make sense to notify V5 
Layer 2 about V5 Layer 1 failure via V5 system management. Instead, 
V5 Layer 2 SHALL be notified directly by V5 Layer 1 on the SG. V5 
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Layer 1 SHALL report the outage to V5 system management by sending a 
Link Status Indication message with status NON-OPERATIONAL, 
corresponding to an MPH-DI primitive as defined by the V5.2 standard. 
V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind 
primitive to V5 Layer 2 in response to this message. 


5.2. Loss of V5UA peer 


If SCTP failure is detected or the heartbeat is lost, the following 
procedure SHALL be performed: 


When loss of V5UA peer is reported to the V5UA layer, the ASP SHALL 
behave as if it had received a Link Status Indication (non- 
operational) for all links on this SG. 


The ASP SHALL attempt to re-establish the connection continuously. 
When the connection is re-established, the ASP SHALL send a Link 
Status Start Reporting message to the SG for all links on active V5 
interfaces on the SG. 


An example for the message flow for re-establishment of the 
connection is shown below for one active link on the SG: 


ASP SG 


| -------- Link Status Start Reporting --------- > | 


<------ Link Status Ind (operational) --------- 


If the association can be re-established before the V5UA layer is 
notified, communication SHALL proceed as usual and no other action 
SHALL be taken by the ASP. 


5.3. C-channel overload on SG 


If the SG detects an overload condition on a C-channel, it SHOULD 
indicate this by sending an Error Indication message, with the reason 
Overload to the MGC. The MGC SHOULD then take appropriate actions to 
clear this overload condition. 


The SG SHALL resend the Error Indication message with the reason 


Overload as long as the overload condition persists. An interval of 
120 seconds for resend of this message is RECOMMENDED. 
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6. Examples 
6.1. Link Identification Procedure (successful) 


The Link Identification Procedures themselves are described by the 


V5.2 standard [3]. 


A message flow example for an LE initiated Link Identification 


procedure over V5UA is shown below. 


ASP and SG is established prior to the following message flows, 


An active association between 
and 


the V5 interface is already in service: 


ASP 


SG 


srr Data Request (LnkCtrl: FE-IDReq) ------> 
<-- Data Indication (LnkCtrl Ack: FE-IDReq) --- 
| <---- Data Indication (LnkCtrl: FE-IDAck) ----- | 
| =--- Data Request (LnkCtrl Ack: FE-IDAck) ----> | 
S SF Sa-Bit Status Request sad) :==2=======> 
<--- Sa-Bit Status Indication Sa7, ZERO ) --- 
| ------- Data Request (LnkCtrl: FE-IDRel) ----- > | 
| <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- | 
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The next example also shows a Link Identification procedure, but this 
time it is initiated by the AN. Again, the ASP association and the 
V5 interface are already in service: 


ASP SG 
<---- Data Indication (LnkCtrl: FE-IDReq) ----- | 
-- Data Request (LnkCtrl Ack: FE-IDReq) ------ > | 
== Sa-Bit Set Req ( Sa7, ZERO ) ------> | 
Leraren Sa-Bit Set Conf (Sal) ============== | 
eS Data Request (LnkCtrl: FE-IDAck) -----> | 


| 
| 
| 
| 
| <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- | 
| <---- Data Indication (LnkCtrl: FE-IDRel) ----- | 
| 
| 
| 
| 
| 


---- Data Request (LnkCtrl Ack: FE-IDRel) ----> | 

------------ Sa-Bit Set Req ( Sa7, ONE ) -----> | 

ST SORA Sas“Bit. Set. Cont: (Sa 1) =========H= 
7. Security Considerations 


The security considerations discussed for the 'Security 
Considerations for SIGTRAN Protocols’ [5] document apply to this 
document. 


8. IANA Considerations 
8.1. SCTP Payload Protocol Identifiers 


IANA has assigned a V5UA value for the Payload Protocol Identifier in 
the SCTP DATA chunk. The following SCTP Payload Protocol identifier 
is registered: 


VSUA mon 


The SCTP Payload Protocol identifier value "6" SHOULD be included in 
each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA 
protocol. The value "0" (unspecified) is also allowed but any other 
values MUST not be used. This Payload Protocol Identifier is not 
directly used by SCTP but MAY be used by certain network entities to 
identify the type of information being carried in a Data chunk. 
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The User Adaptation peer MAY use the Payload Protocol Identifier as a 
way of determining additional information about the data being 
presented to it by SCTP. 


8.2. V5UA Port Number 


IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA. 
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